Description

This PR solves a situation when the management network interface does not have a defined IP address.
When this interface is a bridge, the management ip can be placed directly in the bridge (more common) and sometimes in virtual interfaces linked to it.
On this scenarios, the cloudstack agent iterates over all interfaces and select the first one with a valid ip address.
This brings unpredictable behavior, like choosing wrong interface address, and publishing this address to management servers, causing problems with migrations, guest consoles for example.

I've added two new ways to search for the correct management address:

• First and more "secure" is to explicitly define the management ip address on agent.properties. The agent will find the interface bound to this address and configure it as private interface.
• If configuring this address is not desirable, agent will get the management server addresses, and try to establish a socket (without tcp overhead) with it. If it suceeds, will possible to collect the source ip address used to reach management servers. I belive that this is a more assertive way to find out the host management address.
  If the above methods don't work, the actual behavior is used without changes.

1. Setup a Full L3 network design, with management defined as a traffic label over a "virtual physical address".
2. Create a bridge and setup a vxlan interface with this bridge as master interface.
3. Define a veth interface and define the bridge as master for this interface too.
4. Derfine in this veth interface, the IP address that will be used to reach the management servers.
5. Theres no guarantee that this will be the IP address reported to the management server.

Fixes: #13519

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

I have two hipervisors in production with this changes. Whitout it, I can't make my cluster to work well, cause I can't do migrations and open guest instances terminal
To test it I used both the explicit configuration and route based detection for several days, marking servers for maintenance, rebooting hypervisors and management servers.

How did you try to break this feature and the system with this change?

Configuring an invalid Ip address as management address. The setting was ignored as expected, because no interface was found with it. System fallback to another methods.